feat(releases): surface the branch a snapshot came from, and filter by it - #7
Merged
Conversation
…y it Scan.ref was stamped at scan-create and then invisible: no response field, no filter, nothing in the UI. A project scanning several branches showed one interleaved list with no way to tell the rows apart or narrow to one. ReleaseSnapshot now carries ref, the Releases table has a Branch column, and both the releases and project-scans lists take ?ref= (bare or fully-qualified, normalized like scan triggers). Releases covers succeeded scans only; the scans list keeps a branch's failed attempts visible.
Five test factories construct the wire type literally, so adding a required field breaks them. Local `tsc --noEmit` misses this — the CI typecheck runs `tsc -b`, which builds the test project too.
This was referenced Aug 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scan.refhas been stamped at scan-create for a while — normalized, indexed, and used by retention — but no read path exposed it. No response field, no filter, nothing in the UI. A project scanningmain,release/1.xand PR branches showed one interleaved list of snapshots with no way to tell which row came from where, let alone narrow to one branch.ReleaseSnapshotnow carriesref, the Releases table gains a Branch column, and bothGET /projects/{id}/releasesandGET /projects/{id}/scanstake?ref=. Bare branches and fully-qualified refs both work — the endpoints normalize through the samenormalize_refthe scan-create path uses, so a branch reaches its own rows either way, and the filter is applied to the count so a filtered page does not report the unfiltered total.The two lists stay distinct on purpose: releases covers succeeded scans, so it is a branch's usable history, while the scans list covers every status and is where a branch's failed attempts remain visible.
An ad-hoc scan carries no ref, and the cell says so rather than rendering blank — blank reads as missing data when it is actually a real state.
Second of three follow-ups after #6 fixed the ref-blind anchor. The remaining one is accepting
?release=as an anchor on the detail endpoints.